this is an update to #78. I found it cleaner and more convenient to just cherry-pick my changes in the latest google/jsonapi.

All comments made to the last PR should be addressed here. Addressing the last comment in that PR required some refactor/enhancements, hence took some time.

I think some additional tests should be added to demonstrate what should happen when fields are overlapping. Ie both have a field w/ primary annotation or an attr with the same name has been used.

I added these additional examples:

• response_test.go:1135: running scenario: Model embeds Thing, models have no annotation overlaps
• response_test.go:1135: running scenario: Model embeds Thing, overlap Buzz attribute
• response_test.go:1135: running scenario: Model embeds Thing, attribute, and primary annotation overlap
• response_test.go:1135: running scenario: Model embeds Thing, but is annotated w/ ignore

The expected behavior is that it will behave in the "expected" composition behavior; it will handle the top-level struct fields first, then handle any embedded structs after that. So in the scenario where there is a top-level struct that has a primary annotation, that embeds another struct also containing a primary annotation, the top-level attribute wins. (In the below example, the expected jsonapi payload should have a data/resource type of "posts")

type Post struct {
	Blog
	ID            uint64     `jsonapi:"primary,posts"`
	BlogID        int        `jsonapi:"attr,blog_id"`
	ClientID      string     `jsonapi:"client-id"`
	Title         string     `jsonapi:"attr,title"`
	Body          string     `jsonapi:"attr,body"`
	Comments      []*Comment `jsonapi:"relation,comments"`
	LatestComment *Comment   `jsonapi:"relation,latest_comment"`
}

Lastly, I felt it was getting complex and a bit messy, so I started splitting out unmarshalNode() into smaller functions for better readability.

Happy to add something to the readme.md if you think that would be useful